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[57J ABSTRACT 

Improved key management is provided by a public key 
replacement apparatus and method for operating over inse- 
cure networks. An active public key and the mask of a 
replacement public key are provided by a key server to 
nodes where the active key is used to encrypt and verify 
messages. To replace the active public key with the replace- 
ment public key, a key replacement message is sent to the 
node. The key replacement message contains the replace- 
ment public key and contains the mask of the next replace- 
ment key. The mask of the replacement public key may be 
generated by hashing or encrypting. The key replacement 
message is signed by the active public key and the replace- 
ment public key. Nodes are implemented by a computer, a 
smart card, a stored data card in combination with a publicly 
accessible node machine, or other apparatus for sending 
and/or receiving messages. In a particular application, a 
financial transaction network nodes are consumer nodes, 
merchant nodes, or both, and transactions are securely sent 
over a possible insecure network 

20 Claims, 5 Drawing Sheets 
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KEY REPLACEMENT IN A PUBLIC KEY 
CRYPTOSYSTEM 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the xerographic 
reproduction by anyone of the patent document or the patent 
disclosure in exactly the form it appears in the Patent and 
Trademark Office patent file or records, but otherwise 
reserves all copyrights whatsoever. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to the field of secure trans- 
action processing, more specifically to the field of public key 
encryption of transaction data. 

2. Background Art 

A cryptographic system is a system for sending a message 
from a sender to a receiver over a medium so that the 
message is "secure", that is. so that only the intended 
receiver can recover the message. A cryptographic system 
converts a message, referred to as "plaintext" into an 
encrypted format, known as "ciphertext." The encryption is 
accomplished by manipulating or transforming (he message 
using a "cipher key" or keys. The receiver "decrypts" the 
message, that is. converts it from dphertext to plaintext, by 
reversing the manipulation or transformation process using 
the cipher key or keys. So long as only the sender and 
receiver have knowledge of the cipher key, such an 
encrypted transmission is secure. 

A "classical" cryptosystem is a cryptosystem in which the 
enciphering information can be used to determine the deci- 
phering information. To provide security, a classical cryp- 
tosystem requires that the enciphering key be kept secret and 
provided to users of the system over secure channels. Secure 
channels, such as secret couriers, secure telephone transmis- 
sion lines, or the like, are often impractical and expensive. 

A system that eliminates the difficulties of exchanging a 
secure enciphering key is known as "public key encryption." 
U.S. Pat. No. 4.405,829 and Diffie and Hellman. "New 
Directions in Cryptography," IEEE Trans. Inform. Theory, 
vol. IT-22, pp. 644-654. November 1976, teach public key 
encryption. With public key encryption, two keys are used, 
a private key and a public key. The keys are symmetrical. 
Lc„ either key can be the public key or the private key — the 
labels "public" and "private" simply identify which key is 
made available to the public, and which key is kept private 
by the "owner" of the key pair. Public key encryption is 
applied to a "message". A message is text graphics, data, or 
other digitized information, and public key encryption is 
used to either encrypt the message making it unreadable by 
anyone unless they have the private key or to create a 
readable message with a digital signature. A digital signature 
is created for a specific message using the private key. Only 
a person with knowledge of the private key is able to create 
a valid digital signature for a given message, so this prevents 
others from generating or altering messages and creating 
forged signatures. 

To keep a message to the key owner private, the sender of 
the message will obtain the recipient's public key and use 
that key to encrypt the message. Before encryption, the 
message is said to be a "plain text" message (although the 
message might not be text at all) and following encryption, 
the message is said to be a "cipher text" message. The cipher 
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text message can only be converted back to the original plain 
text message by a decryptor knowing the recipient's private 
key (the other key in the recipient's key pair). Of course, 
with enough computing power and a poorly chosen encryp- 
5 tion scheme or key pair, a decryptor might be able to extract 
the plain text message without knowing the key. It is 
assumed here that a robust encryption scheme is selected 
such that the private key is indeed required. 
A message is digitally "signed* 1 by the key owner by 

io applying a key and the message to a digital authenticator. 
which outputs a digital signature to be attached to the 
message. The recipient of the message can then apply (he 
message, the digital signature and the key used to generate 
the signature to an authenticator which will indicate whether 

15 or not the digital signature was generated from that exact 
message and the key. With public key signatures, the private 
key is used to generate the digital signature and the public 
key is used to verify the signature. 
In a transaction processing system, such as with the use of 

20 smart cards or terminals, a transaction is formed into a 
message and encrypted using the secret key of the operator 
of the transaction processing system. The term "smart card'* 
refers to a card such as a bank card which contains data 
storage and computing ability, as opposed to a more con- 

25 ventional card, which contains only data storage, typically in 
the form of data stored on a magnetic stripe. A terminal 
might be an automatic teller machine (ATM), a terminal in 
a bank, a home personal computer, or other means for a user 
to send and receive data, 

30 U.S. Pat. No. 4,972.472 issued to Brown et al. shows a 
method and apparatus for changing a master key in a 
cryptographic system. That system provides storage loca- 
tions for three keys: a pending key. an active key and a 
retired key. When a key is to be replaced, the new key is 

35 stored in pending key location. When a key update com- 
mand is given, the existing active key is shifted to the retired 
key location and the pending key is shifted into the active 
key location. The retired key is used for applications which 
have not yet been made aware of the key change. Over time. 

40 applications are made aware of the change and shift over 
from using the retired key to using the active key. 

One disadvantage of the Brown et al. system is that a 
replacement key could be sent by someone with unautho- 

45 rized access to the channel used to transmit the keys. Thus, 
the key replacement apparatus is only useful where the 
channel in which the replacement keys are sent out is secure. 

As should be apparent, anyone knowing the key owner* s 
secret key can pose as the key owner, read the key owner's 

50 messages and create or alter messages sent in the name of 
the key owner. In an insecure system, unauthorized persons 
have the ability to view the traffic between the key server 
and the key users, whether or not such eavesdroppers know 
the secret keys being used. Once a secret key is 

55 compromised, it can no longer serve its purposes of making 
messages private. 

One problem with a distributed system of smart cards or 
terminals is that they are widely distributed and when a 
secret key is compromised, it is impractical for all the 

60 holders of the smart cards or users of terminals to return to 
the central key authority to exchange keys or otherwise 
establish a clear channel to transmit the replacement key. 

Another problem is the rapid and continual increase in 
computing power available. The impending obsolescence of 

63 DES (Data Encryption Standard — a secret key algorithm) is 
in part due to the subsequent developments in computing. At 
one tunc, a noted cryptologist calculated that a message 
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encoded with DES could be decrypted without knowing the the key replacement process is performed. Because only the 

secret key in a month using $20 million in computer hash of the replacement public key is available to an 

hardware. Recently, a group of noted cryptographers esti- attacker, increasing computing power does not weaken the 

mated that a $10 million investment in hardware would replacement public key as fast as the active public key. since 

recover a DES key in 6 minutes (see "Minimal Key Lengths 5 manv more operations are needed to determine the replace- 

for Symmetric Ciphers to Provide Adequate Commercial ment public key and to then compute the replacement public 

Security" Blaze et al.. A Report by an Ad Hoc Group of key. Thus, supplying only the hash of the replacement public 

Cryptographers and Computer Scientists, January 1996. kcv untU h is necded at Ac active P ubbc ke y ncI P s ensure 

published at http://ww.bsa.orgA5sa/cryptologist.html). ^ * e repl**™** key cannot be computationally deter- 

Hius. what is needed is a capability to increase security of 10 ^ Wlth . *f same order of ™S™Uide of computing 

keys as large amounts of raw computing power becomes ^ke^ '° COmpUtaU ° nalJy dctcmuflC thc actlvc 

more accessible to potential attackers. pu c ey. 

In an alternate embodiment of the invention, thc replace- 

SUMMARY OF THE INVENTION ment P^lic kev is encrypted instead of using the hash of the 

replacement public key. When the active private key has 

Improved key management is provided by virtue of the 15 been compromised or is at risk of calculation, the key server 

present invention. Thc present invention provides an active sends out a key replacement message containing the replace- 

public key and a "masked" replacement public key to nodes ment key and the encrypted next replacement key, replaces 

of a network. Herein "masked" or 'the mask of* refers to the active private key from the replacement private key 

any manner of securing the replacement key so that it is storage and places the encrypted next replacement private 

computationally difficult to determine the replacement key 20 tev &to the replacement private key storage. The key 

from its masked version. In one embodiment of the inven- replacement message also contains the key for decrypting 

tion the masking of the replacement key is accomplished by mc replacement public key and the message is signed by the 

hashing the replacement public key. An active public key a u ctive Private key and the replacement private key. Because 

and the hash of the replacement public key are provided by ^ , mcss ?S c 15 bv ^"^nt private key it 

a key server to nodes of the network. Each time a key * C0l f d °^ t comt fr ° m ™ cim 2 Wlth ^owied^ of the 

replacement is performed, the active public key is discarded ^ Vat * key ^L** meSS f & was * cnt ™ e 
*u _i ♦ Li- r i .u 7 decryption used on the encrypted next replacement key need 
the replacement public key replaces the active public toy. aot sarae as ^ US ^ 0Q me encrypted replacement 
and the next replacement public key replaces the replace- j^y r 
ment public key. Thus, two public keys art ^cognizable at ^ mc cmbodiment multi le Dodes of an msecure 
a node at any one Ume. These keys are network-wide keys network ^ e dcftned b thc m £ conncctcd coraputcrs 
and are used in addition to any node-specific key pairs. (pcrsonal computerSi ctc .) configured with the 
Each node includes a system for sending and receiving ability to send messages from one node to another or from 
messages to and from the network, such as a networked one node to j^ny nodeSt At eacn nodet m e m ory is main- 
personal computer, a smart card, or a data card combined 35 tamcd w itn the active keVt ^ of me re p]a CC - 
with a public terminal. Initially, each node is provided with menl public key , ^ ^ node > s specific pr ivate/public key 
the active public key and the hash of the replacement public pa^. Typically, a node is associated with one user, such as an 
key. along with any default node "owned" key pairs. The individual using the node to send messages to other users at 
network-wide public keys have corresponding private keys other nodes. For example, a node could be a personal 
which are owned by the operator of the network. The initial ^ computer connected to the Internet and the messages could 
keying of the node is done over a secure channel between the be financial transactions transmitted by the user to banks 
node and the network operator. While other secure channels and/or merchants. 

are possible, the simplest method is for the ^network operator ^ ^ aiternate 'specific embodiment, the key user uses a 

to maintain control over some element of the node during the smajt ^ t0 store mc ^ bUc k and ^ ^ of mc 

process of installing the initial public key information. 45 rep iacement public key, the key server is a financial insti- 

A node uses the active public key (the network active tution and the message sent between thc key user and the key 

public key) to encrypt or sign messages destined for the key server are financial transactions. In yet another embodiment, 

server or a third party. When the active private key has been user specific data is stored on a card held by the user and the 

compromised or is at risk of calculation, the key server sends card is inserted or read by a publicly available terminal to 

out a key replacement message containing the replacement ^ form the node system. 

key and the hash of its own replacement key, replaces the ^ othcr embodiments, a node maintains multiple sets of 

active private key from the replacement private key storage activc ^ of repiacement public keys, one from each 

and places the next replacement private key into the replace- of a plurality of master nodes. This allows for independent 

menlprivate key storage. As should be apparent, according sccure communications with different master nodes, 

to this chain of succession each new key (public or private) 55 A furmer of me Qaturc and advantages of 

is first a next replacement key. then a replacement key, then mc mvcations hcreio ^ ^ rcali2ed by refeeQce * to me 

an active key then finaUy it is discarded. At the node, the rcmaining ^ of me specifications and the attached 

active public key is replaced with the replacement public drawines 

key and the hash of the replacement public key is replaced 4 

with the hash of the next replacement public key. ^ BRIEF DESCRIPTION OF THE DRAWINGS 

The key replacement message is signed by the active FIG. 1 is a block diagram of a network in which the 

private key and the replacement private key. Because the present invention is used; 

message is signed by the replacement private key. it could FIG. 2 is a flow chart of a process of replacing a key in 

only come from an entity with knowledge of the replace- a secure manner; 

ment private key before the message was sent 65 FIG. 3 is a block diagram of a specific application wherein 

If brute force computation of the active public/private key the network is used to carry secure traffic between constim- 

pair becomes feasible, that pair is deemed compromised, and ers and merchants; 
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FIG. 4 is a schematic diagram of a portion of a key 
replacement message; 

FIG. 5 is a block diagram of a network in which an 
alternate embodiment of the present invention is used; 

FIG. 6 is a flow chart of a process of replacing a key in 
a secure manner in an alternate embodiment of the inven- 
tion; and 

FIG. 7 is a schematic diagram of a portion of a key 
replacement message in an alternate embodiment of the 
invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

A system for key replacement in a public key cryptogra- 
phy system is described. In the following description numer- 
ous specific details, such as key length, encryption 
algorithm, etc., are set forth in detail in order to provide a 
more thorough description of the present invention. It will be 
apparent, however, to one skilled in the art., that the present 
invention may be practiced without these specific details. In 
other instances, well known features have not been 
described in detail so as not to unnecessarily obscure the 
present invention. 

FIG. 1 is a block diagram of a network 10 which connects 
two nodes 12 (user node 1 and user node 2) to each other and 
to a key server 16. Although only two nodes are shown for 
clarity, it should be apparent that many more nodes are 
possible. As should also be apparent, network 10 need not be 
actually insecure, but is assumed to be so. An insecure 
network is a network where the possibility exists that an 
eavesdropper 18 is listening to network traffic. 

Each node 12 is shown coupled to its own data key 
storage 20. User node 1 is shown with a message block 22 
containing a message intended for delivery over network 10 
to user node 2. Data key storage 20 contains storage for the 
active public key. a masked version of the replacement 
public key (here the hash of the replacement public key) and 
the user node's private/public key pair. Topically, the nodes 
are associated with individuals and organizations who are 
network users and operate and control their respective 
nodes, to send messages as desired, read received messages, 
change the user node key pair and publish the user node 
public key. 

In the present invention, the hash of the replacement 
public key may be generated using any of several well 
known algorithms such as the MD5 algorithm or the SHA 1 
algorithm or any other suitable hashing algorithm. 

The following notation is used herein: * 4 A* refers to the 
active key pair, with "Apu" being the active public key and 
"Apr" being the active private key. Likewise, the replace- 
ment key pair is **R*\ with "Rpu" being the replacement 
public key and "Rpr" being the replacement private key. The 
hash of a message M using a key K is written as H(M). 

The user key pair is denoted by "IT, with the public and 
private keys being "Upu" and "Upr" respectively. A user key 
pair is distinguished from the active key pair and the 
replacement key pair in that the latter two pairs are used 
system wide, while a user key pair is generated and main- 
tained by the user of a specific node. 

Often, to ensure that the contents of a message have not 
been altered and to verify the node from which a message 
was sent, the message is "digitally signed". To digitally sign 
a message, a node generates a digital signature block from 
the message contents and the node's private key as is known 
in the art The digital signature block is then attached to the 
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message. Because of the way the digital signature block is 
generated, it would be extremely difficult to determine a 
digital signature block for a message without knowing the 
private key used, and the digital signature blocks for the 

5 original message and an altered version of that message are 
unlikely to be the same. In a digital signature system, the 
recipient can apply the message, the digital signature block 
and the sender's public key to a signature verifier. The 
signature verifier reports whether or not that message was 

lo the exact message used to generate the digital signature. 
Herein, a message with a digital signature is denoted as (M) 
[KJ. where M is the message and |K| is the digital signature 
generated for message M using key IC 

In the example described below, only one master node is 

15 used and the operator of that node controls key server 16 and 
thus controls, or "owns", the active public/private key pair 
and the replacement public/private key pair. Thus, the opera- 
tor of key server 16 knows, and keeps secret the active 
private key and the replacement private key. In some 

20 systems, the active and replacement key pairs are referred to 
as "system key pairs" to distinguish them from user key 
pairs. 

In FIG. 1, key server 16 is shown coupled to a key server 
public key database 24 for holding the public keys of each 

25 participating node. Key server 16 is also shown coupled to 
receive "replace key" commands from a central public key 
controller 26, which is in turn coupled to storage 28 for the 
active private key (Apr) and storage 30 for the replacement 
private key (Rpr). Key server 16 sends messages, such as 

30 message 40 and key replacement message 42 to nodes 12 
over network 10. In a preferred embodiment, storage 28 and 
storage 30 are not located in the same physical location or 
secured by a common security method, so that a single 
breach of security which allows access to one key will not 

35 allow access to the other key. 

It is assumed that eavesdropper 18 has the capability to 
send messages which appear to be sent by a node other than 
itself, such as node 12 or key server 16. With this capability. 

^ eavesdropper 18 might send a key replacement message to 
user node 1 falsely indicating that the message was sent by 
key server 16. This forged message would instruct user node 
1 to update Apu to a value provided (apparently) by key 
server 16, If eavesdropper 18 sends a false Apu value which 

45 is paired with a private key known to eavesdropper 18. and 
if user node 1 accepts the message as authentic and changes 
Apu, eavesdropper 18 will be able to decrypt all subsequent 
messages encrypted with the false Apu. Eavesdropper 18 
could also send key server 16 a message apparently from 

^ user node 1 where the message indicates that user node 1 has 
changed its user public key. Ulpu, to a public key which is 
paired with a private key known by eavesdropper 18. If 
accepted by key server 16. eavesdropper 18 would then be 
able to decrypt any messages from key server 16 which are 

55 encrypted with Ulpu. 

In operation, of course, user nodes 12 and key server 16 
are more cautious. To securely send a message from one 
node to another, the sender must obtain the recipient's real 
public key and use that key to encrypt the message. To know 

$o the real key for the recipient the sender must have some way 
of assuring that the public key for the recipient is correct 
The public keys for specific nodes are obtained by querying 
key server 16, which supplies the public keys from node key 
database 24. These public keys are the keys published by the 

63 user nodes. 

Since network 10 is deemed insecure, it is assumed that 
if user node 1 requests a public key from user node 2. 
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eavesdropper 18 could stand in place of user node 2, 
intercept the request, reply with a key known to eavesdrop- 
per 18. intercept the message and decrypt the message. To 
prevent this scenario, the user nodes supply their public keys 
to key server 16 using a message which could not have been 5 
sent from eavesdropper 18 and which is not readable by 
eavesdropper 18. To do this, key server 16 needs to engage 
in one initial secure interaction with each node, to get the 
node's public key and be assured that it was sent from that 
node. Fortunately, this is easily done during the set-up of a 10 
node. For example, if the node is a personal computer, a 
distribution diskette could contain an initial user key pair or 
the key pair could be distributed over the telephone. If each 
message from a node to key server 16 is digitally signed with 
the node's private key, key server 16 is assured that it was 15 
not sent by eavesdropper 18. If the message is also encrypted 
with the active public key, eavesdropper 18 cannot read the 
message. If one user compromises the private key of its 
node, the security breach is confined to that user's node and 
is easily remedied by sending a new key over a secure 20 
channel to that node (e.g., sending a new smart card to the 
user of the node). However, if the active public key is 
compromised, without more security or protection, each 
node in the entire system would have to be reinitialized with 
the replacement public key over secure channels. The secure 25 
channel is not needed with the present invention where only 
the active key is compromised, whether it be by authorized 
access to storage 28 or by computational brute force. 

Key server 16 accepts key replacement commands from 
central public key controller 26. which decides when to 30 
replace the active public key. Apu. Central public key 
controller 26 generates a new replacement key pair each 
time the active key is to be replaced with the existing 
replacement key, and updates storage 28 and 30 accordingly. 
Herein the new key pair is referred to as (Rlpu. Rlpr), and 33 
subsequently generated new pairs are (R2pu. R2fcr), (R3pu. 
R3pr), etc. The process of secure replacement of the public 
key over an insecure network is shown in FIG. 2. 

FIG. 2 is a flow chart of a process for publishing a public 
key and for replacing a public key when its paired private 40 
key is compromised or insufficiently secure. In the example 
shown, the public key being replaced is Apu, the active 
public key of key server 16. The active public key might not 
be actually compromised, as key replacement might be 
called for as technology advances to the point where it is 43 
conceivable that Apu could be calculated by brute force, in 
which case the replacement key would be a longer or more 
complex key. Alternatively, key replacement could occur on 
a regular, periodic basis, since a secure channel is not 
needed. The process of key replacement must occur both at 50 
key server 16 and at nodes 12, since keys are paired. Thus, 
when the private key is replaced in storage 28, that replaced 
key cannot be used unless the public key stored in data 
storage 20 is also replaced. 

Referring again to FIG. 2, the steps of the process shown 55 
there are labeled SI, S2, S3, etc,, for ease of reference. In 
step SI, Apu and H(Rpu) are supplied initially to each node 
over a secure channel. As explained above, this step need 
only be done once. The key replacement process begins with 
step S2. where a new key pair (Rlpu. Rlpr) is generated), 60 
This is done by either key server 16 or central public key 
controller 26. In step S3, key server 16 sends a key replace- 
ment message (such as key replacement message 42 shown 
in FIG. 1 and in detail in FIG. 4) to each node 12. or 
broadcasts a single key replacement message. A number of 65 
fields of key replacement message 42 are shown in FIG. 4. 
These fields include the replacement public key 150. the 
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hash of the next replacement public key 152. and digital 
signatures for the message 154, 156. 

The entire key replacement message is digitally signed by 
both the active private key. Apr. and the private replacement 
key. Rpr. Additionally, the message might be encrypted 
using the active public key. Apu. However, given that Apu 
might have been compromised, a more secure method is to 
send separate messages to each node, each encrypted with 
the node's public key. If the key replacement message is 
encrypted . it is decrypted by the node. 

FIG. 4 shows key replacement message 42 in greater 
detail. This message 42 is sent from key server 16 to node 
12 as part of the key replacement process. The fields shown 
are Rpr, H(Rlpu). SIG (Apr) and SIG(Rpr). 

The key replacement process has the following steps: 1) 
a new key pair is generated by central public key controller 
26, 2) central public key controller 26 moves the existing 
replacement private key from storage 30 to storage 28. 
making it the new active private key, 3) central public key 
controller 26 moves the next replacement private key to 
storage 30, making it the new replacement private key. 4) 
central public key controller 26 sends a key replacement 
command to key server 16, where the key replacement 
command includes the replacement public key and the hash 
of the public key from the next replacement key pair, and 5) 
the next replacement public key is inserted into message 42 
as field H(Rlpu). This example is for the first generation of 
key replacement. In the second generation, the field is 
designated H(R2pu). to be consistent with the conventions 
used here. Because the keys are paired, these steps must be 
done together, otherwise messages might be encrypted with 
one generation of keys and decryption would be attempted 
with a different generation of keys. 

The field Rpu contains the replacement key. 

The field H(Rlpu) is generated by hashing the next 
replacement public key. now designated Rlpu. according to 
the hashing function H( ). The hashing of Rlpu can be 
performed either by central public key controller 26 of key 
server 16. 

The fields SK3<Apr) and SIG(Rpr) are digital signatures, 
also sometimes referred to as (Apr) and [Rpr], respectively. 
The digital signature SIG(Apr) is a signature of message 42 
using the currently active private key, i.e.. the contents of 
storage 28 before the replacement is done. This digital 
signature is verified by applying message 42 and the other 
key which is paired with the signing key Apr, namely active 
public key Apu. to a verifier. Similarly, the digital signature 
SIG(Rpr) is verified by applying message 42 and the 
replacement public key. Rpu, to the verifier. 

If both digital signatures verify message 42, the node 
replaces H(Rpu) with H(Rlpu) and replaces Apu with Rpu. 
In this way. the active public key stored in storage 20 is 
replaced with the replacement public key, which was also 
stored in storage 20, and the hash of the next replacement 
public key extracted from message 42 is stored in storage 20 
as the hash of the replacement public key. 

Referring again to FIG. 2. in step S4. the digital signature 
(Apr] is verified using Apu. If the digital signature does not 
match the message and the active public key (Apu), then the 
key replacement message is ignored (S5). In some 
embodiments, the node will send a message to key server 16 
to the effect that an unauthorized key replacement message 
has apparently been sent. 

If the digital signature (Apr] is verified, the replacement 
public key. Rpu. is extracted from the key replacement 
message (S6) 
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The replacement public key, Rpu, is used to verity the 
digital signature [Rpr) of the key replacement message (S7). 
If the digital signature |Rpr] does not verify, the process 
flows to step SS. otherwise it continues to step S8. In step S8, 
the node replaces Apu in storage 20 with the replacement 
public key, Rpu and replaces H(Rpu) in storage 20 with the 
hash of the next replacement public key. H(Rlpu) (S9). 

At this point, key replacement is complete. If desired, the 
process can be repeated (SIO) so that yet another new key 
pair (R2pu, R2pr) is generated, where R2pu becomes the 
replacement key with Rlpu being the active key. Performing 
the process twice is useful where both the active key and the 
replacement key are nearing obsolescence. If the replace- 
ment key is never generally available, i.e., only its hash is 
generally available, any computation to break the keys will 
take longer to break the replacement key than the active key. 
since the replacement public key must be broken before the 
replacement private key can be attacked. 

If the replacement private key is physically compromised, 
but the active private key is not, this method will still 
securely transmit the key replacement message over the 
insecure network, since it is signed by the active private key. 
Of course, in this situation, the key replacement would be 
done twice in quick succession, in order to retire the 
compromised replacement key. 

In an alternate embodiment, the masking of the replace- 
ment public key can be accomplished by encrypting it FIG. 
S illustrates a system similar to the system in FIG. 1- Like 
dements have been given like numerals in FIGS. 1 and 5. 
One difference in FIG. 5 is that in data key storage 20A. the 
encrypted replacement public key is stored instead of the 
hash of the replacement public key. 

The following notation is used in connection with FIG. 5: 
"A* refers to the active key pair, with "Apu" being the active 
public key and "Apr** being the active private key. Likewise, 
the replacement key pair is "R", with "Rpu" being the 
replacement public key and "Rpr** being the replacement 
private key. Encryption of a message M using a key K is 
written as E_K(M), while decryption of the encrypted 
message E_JC(M) using key K is written as D_K(EL_K(M) 
). This notation refers to both secret key encryption and 
public key encryption, although when referring only to 
public key encryption, the more specific notation E_JKpu 
(M) and D_Kpr (M) is used to clearly indicate the different 
components of the key or key pairs are used for encryption 
and decryption. The functions E_K( ) and D_K( ) need not 
be distinct. For example, where encryption is the exclusive 
OR'ing of the message and the key. E_K( ) and D_K( ) arc 
the same functions. 

FIG. 6 is a flow chart similar to FIG. 2 but showing a 
process using encryption for publishing a public key and for 
replacing a public key when its paired private key is com- 
promised or insufficiently secure. In FIGS. 2 and 6, like 
elements have like numbers. In the example shown, the 
public key being replaced is Apu, the active public key of 
key server 16. The active public key might not be actually 
compromised, as key replacement might be called for as 
technology advances to the point where it is conceivable that 
Apu could be calculated by brute force, in which case the 
replacement key would be a longer or more complex key. 
Alternatively, key replacement could occur on a regular, 
periodic basis, since a secure channel is not needed. The 
process of key replacement must occur both at key server 16 
and at nodes 12. since keys are paired. Thus, when the 
private key is replaced in storage 28, that replaced key 
cannot be used unless the public key stored in data storage 
20 A is also replaced. 
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Referring again to FIG. 6. the steps of the process shown 
there are labeled S1A. S2. S3A, etc.. for ease of reference. 
In step SIA. Apu and E_X(Rpu) arc supplied initially to 
each node over a secure channel. As explained above, this 

5 step need only be done once. The key replacement process 
begins with step S2, where a new key pair (Rlpu. Rlpr) is 
generated. This is done by either key server 16 or central 
public key controller 26. In step S3A, key server 16 sends a 
key replacement message (such as key replacement message 

10 42 shown in FIG. 5 and in detail in FIG. 7) to each node 12, 
or broadcasts a single key replacement message. A number 
of fields of key replacement message 42 are shown in FIG. 
7. These fields include the next replacement public key 
150A. data necessary to decode the replacement public key 

15 152A. 154A, and digital signatures for the message 156A. 
158A. 

The entire key replacement message is digitally signed by 
both the active private key, Apr. and the private replacement 
key, Rpr. Additionally, the message might be encrypted 

20 using the active public key. Apu. However, given that Apu 
might have been compromised, a more secure method is to 
send separate messages to each node, each encrypted with 
the node's public key. If the key replacement message is 
encrypted , it is decrypted by the node. 

23 FIG. 7 shows key replacement message 42 in greater 
detail. This message 42A is sent from key server 16 to node 
12 as part of the key replacement process. The fields shown 
are X, D_X( ). E_Xl(Rlpu). SIG (Apr) and SIG(Rpr). 
These fields will be described in further detail below. 

30 

The key replacement process has the following steps: 1) 
a new key pair is generated by central public key controller 
26. 2) central public key controller 26 moves the existing 
replacement private key from storage 30 to storage 28. 

35 making it the new active private key. 3) central public key 
controller 26 moves the next replacement private key to 
storage 30, making it the new replacement private key, 4) 
central public key controller 26 sends a key replacement 
command to key server 16. where the key replacement 

^ command includes the new public key from the next 
replacement key pair, and 5) the next replacement public key 
is inserted into message 42 as field E_Xl(Rlpu). This 
example is for the first generation of key replacement In the 
second generation, the field is designated E_X2(R2pu). to 

45 be consistent with the conventions used here. Because the 
keys are paired, these steps must be done together, otherwise 
messages might be encrypted with one generation of keys 
and decryption would be attempted with a different genera- 
tion of keys. 

5q The field X contains the decryption key for E_X(Rpu). 
the encrypted replacement key which resides at the node to 
which message 42 is sent The field D_X( ) contains the 
decryption method for E_X(Rpu). In some embodiments. 
D_X( ) is known ahead of time as the user node, so this field 

55 is not needed. This field contains, depending on 
implementation, parameters and/or program instructions for 
the decoding process. With the X and D_X( ) fields, the 
node can decrypt the replacement public key. 
The field E_JCl(Rlpu) is generated by encrypting the 

go next replacement public key, now designated Rlpu, accord- 
ing to the encryption function E_JC1( ). The encryption of 
Rlpu can be performed either by central public key con- 
troller 26 of key server 16. 
The fields SIG(Apr) and SIG(Rpr) are digital signatures. 

65 also sometimes referred to as [Apr) and [Rpr], respectively. 
The digital signature SIG(Apr) is a signature of message 42 
using the currently active private key, i.e„ the contents of 
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storage 28 before the replacement is done. This digital 
signature is verified by applying message 42 and the other 
key which is paired with the signing key Apr, namely active 
public key Apu. to a verifier. Similarly, the digital signature 
SIG(Rpr) is verified by applying message 42 and the 5 
replacement public key, Rpu, to the verifier. Of course, the 
replacement public key. Rpu, must be decrypted before it 
can be applied to the verifier. 

If both digital signatures verify message 42. the node 
replaces E__X(Rpu) with E_Xl(Rlpu) and replaces Apu io 
with Rpu. In this way. the active public key stored in storage 
20A is replaced with the replacement public key. which was 
also stored in storage 20A. and the replacement replacement 
public key extracted from message 42 is stored in storage 
20A as the replacement public key. Of course the next 15 
replacement public key is encrypted and stored in its 
encrypted form, until the next generation when it is needed 
as the active public key. 

Referring again to FIG. 6. in step S4, the digital signature 
I Apr | is verified using Apu. If the digital signature does not 20 
match the message and the active public key (Apu). then the 
key replacement message is ignored (S5). In some 
embodiments, the node will send a message to key server 16 
to the effect that an unauthorized key replacement message 
has apparently been sent. 25 

If the digital signature [Apr] is verified, the replacement 
public key. Rpu. is extracted from the key replacement 
message (S6A), using the key and decryption method pro- 
vided by the key replacement message. 

Once the replacement public key. Rpu. is decrypted, it can 
be used to verify the digital signature [Rpr] of the key 
replacement message (S7A). If the digital signature [Rpr] 
does not verify, the process flows to step S5. otherwise it 
continues to step S8. In step S8, the node replaces Apu in 35 
storage 20A with the replacement public key, Rpu and 
replaces E__X(Rpu) in storage 20 A with the encrypted next 
replacement public key, E„Xl(Rlpu) (S9A). 

At this point, key replacement is complete. If desired, the 
process can be repeated (S10) so that yet another new key ^ 
pair (R2pu. R2pr) is generated, where R2pu becomes the 
replacement key with Rlpu being the active key. Performing 
the process twice is useful where both the active key and the 
replacement key are nearing obsolescence. If the replace- 
ment key is only ever generally available in encrypted form, 43 
any computation to break the keys will take longer to break 
the replacement key than the active key. since the encryption 
on the replacement public key must first be broken before 
the replacement private key can be attacked. 

If the replacement private key is physically compromised, so 
but the active private key is not. this method will still 
securely transmit the key replacement message over the 
insecure network, since it is signed by the active private key. 
Of course, in this situation, the key replacement would be 
done twice in quick succession, in order to retire the 55 
compromised replacement key. 

FIG. 3 shows a specific application of the key replacement 
system, a financial transaction system 100. Several elements 
of FIG. 1 are shown again in FIG. 3: network 10, eaves- 
dropper 18. node public key database 24. central public key 60 
controller 26. and storage 28 and 30. System 100 is used to 
facilitate a secure transaction, such as a credit or debit card 
transaction between a consumer at a consumer node 102 and 
a merchant at a merchant node 104 via network 10. Con- 
sumer node 102 is implemented as a personal computer, a 65 
smart card, or a publicly accessible terminal. If consumer 
node 102 is a publicly accessible terminal, such as an ATM. 
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kiosk or point-of-sale (POS) terminal, data personal to the 
consumer would be stored separately (labeled "personal 
storage 110" in the figure), and would include key storage 
106 similar to key storage 20 shown in FIG. 1 or 20A of FIG. 
5 and a financial database 108. each coupled to consumer 
node 102. Key storage 106 coupled to the consumer node 
102 stores the central public keys and the consumer's keys, 
public and private, as well as other consumer specific data. 
Merchant node 104 also is coupled to its own key storage 
106. which stores the central public keys and merchant keys. 
If a node 12 is both a consumer and a merchant node, it 
might use the same keys for both buying and selling trans- 
actions. 

A key server 112 is coupled to network 10 and central 
public controller 26. Key server 112 serves the same purpose 
as key server 16 of FIG. 1, as well as an additional purpose 
of being an authorization server which uses secure links to 
a financial network to secure authorization and/or funds for 
transactions entered into by a consumer at consumer node 
102. 

A transaction is shown in FIG. 3 by paths numbered 1 
through 5. A consumer initiates the transaction. For 
example, a consumer might browse publicly available files 
of offerings of a merchant, such as World Wide Web pages 
on the Internet and decide to order a product. To pay for the 
product, the consumer sends a secure message to the mer- 
chant To do this, consumer node 102 sends a public key 
request message to key server 112 (piih 1). Key server then 
responds with a public key value message back to consumer 
node 102 indicating the public key for merchant node 104 
(path 2). These two messages are sent secured by the 
methods described above. The message to key server 112 
and its response are encrypted and/or signed using the public 
and private keys of key server 112, so those keys must be 
kept especially secure. 

The consumer node 102 then sends the transaction data to 
merchant node 104 in a message encrypted with the public 
key for merchant nod 104 and signed by the private key for 
consumer node 102. For example, the message might say 
"charge item #123, quantity 1, to card number 47##-####- 
####-####, expiration date ram/yy". This message is 
decryptable only by the merchant node, since the merchant 
node private key is required for decryption. Merchant node 
104 uses this formation to process the payment over the 
secure financial network. The merchant can verify the sig- 
nature on the transaction using the consumer's public key, 
which can be obtained from key server 112. 

Before submitting the payment over the financial 
network, merchant node 104 can check card authorization 
either through the financial network or through key server 
112 (via path 4), which would then check for authorization 
and secure funds. Key server 112 then (path 5) securely 
reports the results of the authorization to consumer node 102 
as well as merchant node 104. 

As should be apparent the above-described method and 
apparatus might also be used to perform bill payment or the 
secure network might be entirely replaced by network 10, in 
which case issuer banks (who issue credit, debit or bank 
cards to consumers), acquirer banks (who acquire transac- 
tions from merchants), and settlement systems could be 
nodes on network 10. Bill payment might be performed as 
taught by U.S. Pat. No. 5.465.206 (Appl. Ser. No. 08/146, 
515). issued to Hilt, et al. on Nov. 7. 1995, and commonly 
owned with the present application. That patent is incorpo- 
rated by reference herein. 

In summary, the above detailed description has described 
a method and apparatus for securely distributing keys over 
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an insecure network from a central source, to allow secure 
communications between nodes and a key server and from 
nodes to nodes, even where each node has no means to 
verify the identity of any other node except the key server. 
The keys that are distributed are the network public keys. 

The above description is illustrative and not restrictive. 
Many variations of the invention will become apparent to 
those of skill in the art upon review of this disclosure. 
Merely by way of example, the apparatus might be imple- 
mented wholly in general purpose computers suitably pro- 
grammed or could be implemented by special purpose 
hardware or integrated circuitry. Also, the above description 
shows the application of key replacement to the public key 
of a network, i.e., the master node's public key. However, 
the same key replacement methods and apparatus could also 
be used for more secure replacement of user node keys. In 
such a system, the key server would maintain user public 
keys and replacement user public keys. 

The scope of the invention should, therefore, be deter- 
mined not with reference to the above description, but 
instead should be determined with reference to the appended 
claims along with their full scope of equivalents. 

What is claimed is: 

1. A method of secure public key replacement in a public 
key cryptography system, wherein secure messages are 
transmitted from a first node to a second node over a 
network presumed to be insecure, the method comprising 
the steps of; 

generating, at the first node, an active key pair comprising 
an active private key and an active public key, wherein 
the active key pair is used to secure messages between 
the first and second nodes according to a public key 
scheme; 

generating, at the first node, a replacement key pair 
comprising a replacement private key and a replace- 
ment public key; 

generating at the first node, a mask of the replacement 
public key; 

sending the active public key and the mask of the replace- 
ment public key from the first node to the second node 
over a secure channel; 

when the active key pair is to be retired, rjerfonning the 
steps of: 

generating, at the first node, the next replacement key 

pair comprising the next replacement private key and 

the next replacement public key; 
generating, at the first node, the mask of the next 

replacement public key; 
sending a key replacement message including the 

replacement public key from the first node to the 

second node over the network; and 
verifying, at the second node, the replacement public 

key; and 

thereafter using the replacement key pair as the active 
key pair, for use in securing messages between the 
first and second nodes, and thereafter using the next 
replacement key pair in place of the replacement key 
pair, which is stored for use in a subsequent key pair 
retiring step. 

2. The method of claim 1, wherein the process of retiring 
the active key pair further comprises the steps of: 

sending, from the first node to the second node, the mask 
of the next replacement public key; and 

sending, from the first node to the second node, digital 
signatures for providing to the second node that the 
active private key and the replacement private key were 
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known to the initiator of the process for retiring the 
active key pair. 

3. The method of claim 1. further comprising the step of 
sending a message from the first node to the second node. 

5 wherein the message is digitally signed using either the 
active private key or the replacement private key or both. 

4. The method of claim 1. further comprising the step of 
sending a message from the second node to the first node, 
wherein the message is encrypted using either the active 

10 public key or the replacement public key or both. 

5. The method of claim 1, wherein replacement of the 
mask of the replacement public key with the mask of the 
next replacement public key is performed at the second node 
and is performed synchronously with the replacement of the 

15 active private key with the replacement private key and the 
replacement of the replacement private key with the next 
replacement private key at the first node. 

6. The method of claim 1. wherein the first node is a key 
server node and the second node is one of a plurality of user 

20 nodes. 

7. The method of claim 1. wherein the first node is one of 
a plurality of user nodes and the second node is a key server 
node. 

S. The method of claim 1. wherein the network connects 
25 a plurality of nodes to each other, the plurality of nodes 
comprising a plurality of key server nodes and a plurality of 
user nodes. 

9. The method of claim 1. further comprising the step of 
repeating the step of retiring a key pair. 
30 10. The method of claim 1 wherein said step of generating 
the mask of the replacement public key is accomplished by 
generating a hash of the replacement public key. 

11. The method of claim 10 wherein said step of gener- 
ating a hash of the replacement public key is accomplished 

35 by using MD5 hashing algorithm. 

12. The method of claim 10 wherein said step of gener- 
ating a hash of the replacement public key is accomplished 
by using SHA 1 hashing algorithm. 

13. The method of claim 1 wherein said step of generating 
40 the mask of the replacement public key is accomplished by 

encrypting the replacement public key. 

14. A method of secure public key replacement in a public 
key cryptography system, wherein a first node stores an 
active private key and a second node stores an active public 

45 key and a replacement public key. the active public bey and 
the active private key being an active key pair used for 
public key cryptography and the replacement public key and 
the replacement private key being a replacement key pair, 
and wherein the replacement public key is stored as an 
50 encrypted replacement public key at the second node, the 
method comprising the steps of: 

generating, at the first node, a next replacement key pair 
comprising a next replacement private key and a next 
replacement public key; 
55 generating, at the first node, a mask of the next replace- 
ment public key; 
sending the replacement public key from the first node to 
the second node; 
60 verifying, at the second node, the encrypted replacement 
public key; and 
thereafter using the replacement key pair as the active key 
pair, for use in securing messages between the first and 
second nodes, and thereafter using the next replace - 
65 ment key pair in place of the replacement key pair, 
which is stored for use in the subsequent key pair 
retiring step. 
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15. The method of claim 14. wherein the step of sending 
the replacement public key from the first node to the second 
node is performed over a network presumed to be secure, 

16. The method of claim 14 wherein the step of generating 

a mask of the replacement public key is accomplished by 5 
generating a hash of the replacement public key. 

17. The method of claim 16 wherein said hash is gener- 
ated using the MD5 hashing algorithm. 

18. The method of claim 16 wherein said hash is gener- 
ated using the SHA 1 algorithm 10 

19. The method of claim 14 wherein the step of generating 
the mask of the replacement public key is accomplished by 
encrypting the replacement public key. 

20. A method of secure public key replacement in a public 
key cryptography system, wherein secure messages are 15 
transmitted from a first node to a second node over a 
network presumed to be insecure, the method comprising 
the steps of: 

generating, at the first node, an active key pair comprising 
an active private key and an active public key, wherein 20 
the active key pair is used to secure messages between 
the first and second nodes according to a public key 
scheme; 
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generating, at the first node, a replacement key pair 
comprising a replacement private key and a replace- 
ment public key; 

sending the active public key and the replacement public 
key from the first node to the second node over a secure 
channel; 

when the active key pair is to be retired, performing the 
steps of: 

generating, at the first node, a next replacement key 
pair comprising a next replacement private key and 
a next replacement public key; and 

sending the next replacement public key from the first 
node to the second node over the network: and 

thereafter using the replacement key pair as the active 
key pair, for use in securing messages between the 
first and second nodes, and thereafter using the next 
replacement key pair in place of the replacement key 
pair, which is stored for use in a subsequent key pair 
retiring step. 

***** 
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